Various apparatus such as game consoles, desktop computers, laptop computers, smartphones, tablets, servers, integrated circuits and other devices may employ video image compression and/or decompression to reduce the bandwidth used to communicate video images which may be made up of large amounts of pixel data. Compressing video images can also speed up operation of computing devices or systems and/or reduce memory costs and overall system costs.
An example of an industry standard video image compression technique is referred to as Display Stream Compression (DSC) which is a VESA industry standard for real-time lossy image compression. Display manufacturers are producing high resolution displays to differentiate their products and increased pixel counts require increased bandwidth over the links that drive these displays. Accordingly, compressing the video images prior to communicating the information over display links is a much desired solution. The display stream compression standard (such as DSC 1.2a), is typically employed in video system since it allows for a display stream (i.e., sequence of image frames) to be compressed in raster scan order. For example, input pixels are scanned in line by line from left to right by the encoder that compresses the source images. The DSC standard defines a method for both the encoding operation and the decoding operation.
Referring to FIG. 1, a block diagram of an encoding system such as one compliant with DSC 1.2a industry standard shows a source image 100 which is an image in a video sequence for display on a display 102. The source image 100 is compressed by an encoder 104 which produces a bitstream 106 which is transmitted via display link either wirelessly or in a wired fashion (including optical) to a decoder 108 and is typically located within the display 102. The decoder 108 decompresses the compressed image in the bitstream 106 and the display 102 displays the source image frame as a reconstructed image frame 110 on the display 102. The encoder 104 uses a single indexed color history buffer shown as 112 to encode the source image into an encoded bitstream 106 for display on a single display. The decoder 108 also has a copy of the ICH buffer 112 shown as ICH buffer 114 which is used in the decoding process to decode the encoded bitstream 106 and produce the reconstructed image 110.
Referring also to FIG. 2, in DSC 1.2a, the source image 100 which has a certain resolution defined by its picture height 200 and its picture width 202 based on a number of pixels in the vertical and horizontal directions that are on the display, as known in the art. The picture height (PIC_HEIGHT) in the picture width (PIC_WIDTH) corresponds to the pixels in the vertical and horizontal direction on the single display that will display the source image when it is decoded. The SLICE_WIDTH 206 is the horizontal pixel slice width. In this example, a source image that is to be displayed on a single display is segmented into horizontal slices having the same width. The source image 100 is broken up into equal sized segments called “slices” shown as 204. Each slice is coded independently from all other slices. The independence between slices allows for an image to be compressed by one DSC encoder or multiple DSC encoders each having a single indexed color history buffer, as long as the assembled bitstream 106 is DSC 1.2a compliant. In this example, the input image or source image is segmented into four slices in the horizontal direction and two slices in the vertical direction. The number of slices in the horizontal and vertical directions can be arbitrary. Each slice is compressed (i.e., encoded) using a combination of four different algorithms: a Modified Medium-Adaptive Prediction (MMAP) algorithm, a Mid Point Prediction (MPP) algorithm, a Block Prediction (BP) algorithm and an Indexed Color History (ICH) algorithm.
Considering slices in the horizontal direction, the ICH buffer is a history cache which stores previously coded pixels. In the DSC 1.2a standard the ICH buffer is a 32-entry pixel history cache however any suitable configuration may be used. The DSC 1.2a encoder and a DSC 1.2a decoder are required to maintain identical ICH buffer state. If source image pixels exist in the ICH buffer, based on weighted selection criteria, the ICH buffer entries containing the source image pixels can be referenced via their indices and coded into the DSC 1.2a Bitstream. Depending on the source image content, the cost of referencing pixels in the ICH buffer can be less than the cost of the MMAP, MPP, and BP coding algorithms in terms of bits. It is desirable to encode pixels with the least amount of bits as possible as this frees up additional bits in DSC 1.2a's bit budget for regions of the image that are harder to compress and, therefore, require more bits. Since the encoder and decoder maintain identical ICH buffer states, the decoder can reconstruct the source pixels from the ICH buffer using the referenced indices.
On the first line of each slice, all 32 entries of the ICH point to previously coded pixels. On all other lines of the slice, the first 25 entries point to previously coded pixels (e.g., most recently used) while the remaining 7 entries point to pixels to the left, directly above, and to the right of the current pixels being coded.
The DSC 1.2a standard mandates the following ICH buffer behaviors. For images that have exactly one slice in the horizontal direction, at the beginning of each slice, all entries of the ICH are reset (invalidated). For images that have more than one slice in the horizontal direction, at the beginning of each slice, all entries of the ICH are reset (invalidated) and at the beginning of all other lines of each slice, the first 25 entries which point to actual history entries are reset (invalidated).
Based on the DSC 1.2a ICH buffer behavior and the fact the DSC 1.2a is designed to process images in raster scan order, ICH buffer elements can be reused when the encoder and decoder transition from one line of a slice to the next line of a slice in the horizontal direction. It should also be noted that the number of slices in the vertical direction have no impact on the ICH buffer behavior as the next vertical slice coding does not start until the current vertical slice coding has completed. Thus, the mandated ICH buffer behavior in DSC 1.2a requires a single instance of an ICH buffer in an encoder and decoder.
However, when encoding for multiple different displays, each having its own bitstream, the encoder 104 using the ICH buffer invalidation behavior for multiple slices in the horizontal direction, is forced to invalidate the shared ICH buffer elements and a bitstream carrying only a single horizontal pixel slice for a display would have incorrect ICH invalidation behavior. When bitstream 106 is split into one bit stream per horizontal slice, the ICH reset behavior for each slice is “Reset at beginning of slice and each line of each slice” because the encoder uses the DSC 1.2a standard reset behavior. When each decoder device receives it's (split) bitstream, it is expecting that the ICH Is reset only at the beginning of each slice. There would be a mismatch between the encoder and the decoder in that the expected ICH reset behavior in the decoder would not match the actual reset behavior used. This would lead to incoherent ICH buffers and would cause a corrupted image to be displayed on the decoder device.
One solution is to duplicate the encoder 104 and its associated ICH buffer 112 for each display for which the source image 100 is displayed on. However, replicating the encoders 104 multiple times is very costly in terms of integrated circuit real estate and can increase power consumption which may not be desirable for mobile devices that rely heavily on battery power.